home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 4 / ETO Development Tools 4.iso / Essentials / MacApp Documentation / MacApp.TECH$ Archives / 1988 / Oct⁄Nov 88 / MacApp & Background servers ⁄ < prev    next >
Encoding:
Text File  |  1991-03-06  |  5.3 KB  |  149 lines  |  [TEXT/GEOL]
  1. Item    5322435                         22-Nov-88        05:49
  2.  
  3. From:   UK0004                          Bacchus & Smith, Paul Smith
  4.  
  5. To:     ANDRIEUX1                       Euro Dev Svcs, Alain Andrieux
  6.  
  7. cc:     MACAPP.TECH$                    MACAPP Tech
  8.         UK.DEVSERV                      UK - Product Mktg, J Rose
  9.  
  10. Sub:    MacApp & Background servers
  11.  
  12.  
  13. From:  Dave Jewell, Bacchus & Smith Limited, England
  14.  
  15.  
  16. MultiFinder Server problems
  17. ===========================
  18.  
  19. We are developing, using as a basis a foreground-only AppleTalk server
  20. application we developed some time ago, a background server which sits
  21. in it's own MultiFinder "world" and functions both as an Appletalk-based
  22. server and also makes a number of services available to other applications
  23. running on the same Macintosh. The server has no user interface or windows
  24. of it's own: it reports to the user via the Notification Manager.
  25.  
  26. The existing server is in use in a number of European sites, and supports
  27. 10 to 20 concurrent users on a LocalTalk network, providing comprehensive
  28. (and very fast) B-Tree Indexed File handling services to several large-scale
  29. applications we have developed using MacApp.
  30.  
  31. The server was developed using MPW C 2.0.2. A fully developed calling interface
  32. for MacApp 1.1.1 exists and is proven in real live applications (regarding
  33. recent correspondence in MACAPP.TECH$: if anyone wants to licence this
  34. technology, please 'link us at UK0004).
  35.  
  36. We first thought that by enabling the AppleTalk 'self-send' bit and running
  37. the server on the same machine as the MacApp client application, both under
  38. MultiFinder, that we would have an acceptable system. We expected that there
  39. would be some loss of performance, but the first problem struck...
  40.  
  41.  
  42. First Problem
  43. -------------
  44.  
  45. If the server is packaged as a regular application, it does not get *any*
  46. processor time when another application is active. We therefore set
  47. the server's SIZE resource as follows:
  48.  
  49.     resource 'SIZE' (-1) {
  50.            dontSaveScreen,
  51.            ignoreSuspendResumeEvents,
  52.            enableOptionSwitch,
  53.            canBackground,
  54.            notMultiFinderAware,
  55.            onlyBackground,
  56.            dontGetFrontClicks,
  57.            384 * 1024,
  58.            384 * 1024
  59.         };
  60.  
  61. This is the same combination of SIZE bits as is used by Backgrounder.
  62. (Backgrounder, which looks after Print Monitor, is the closest existing
  63. application to what we want to achieve.)
  64.  
  65. The problem is that the server now gets time, but only a *very* limited
  66. amount. We call WaitNext event with an eventmask of 0 (like Backgrounder).
  67.  
  68. I have put in a temporary piece of code to invert a screen pixel after
  69. each WaitNextEvent call and we only seem to get called maybe 4 or 5 times
  70. a second. Altering the sleep parameter to WaitNextEvent makes no
  71. significant difference.
  72.  
  73. I would have expected that if the active application has no pending
  74. events, then MultiFinder would call the background app much more often.
  75. It does not seem to do this. Four or five times a second is enough for
  76. Backgrounder but not for us. With the server running so slowly, both
  77. remote (i.e. Appletalk requests) and local requests run **very** slowly.
  78.  
  79. Accordingly, we decided to try to provide direct communication between
  80. the server and the foreground application. This is where the second
  81. problem arose...
  82.  
  83.  
  84. Second Problem
  85. --------------
  86.  
  87. We now want our own applications to be able to make direct calls to the server
  88. on the same machine. We need the other apps to be able to "find" the
  89. server and call routines within it. I have written code which swops the
  90. A5 register, etc and this works OK. BUT we need a future-proof mechanism
  91. which enables programs to talk to one another under MultiFinder.
  92.  
  93. One method that works is to use the unassigned exception vector at location
  94. $30 in low memory: changing the value in this vector to point to a jump
  95. instruction which in turn points where the original vector originally pointed.
  96. This means that if the vector ever gets used by Apple or Motorola it will
  97. still work. My application code looks for a signature *after* the jump
  98. instruction. Now, I know this is absolutely against all Guidelines but:
  99.  
  100.     a) At least I haven't grabbed an unassigned A-Trap
  101.     b)  I haven't touched what's on the stack so anything that looks at
  102.        stack return addresses etc *won't* break.
  103.     c)  My client does not want the expense of writing a driver.
  104.     d) It works.
  105.  
  106. Needless to say I would like someone to recommend a more future-proof
  107. (and A/UX-proof) technique.
  108.  
  109.  
  110. Inter-Application Communication under MultiFinder
  111. -------------------------------------------------
  112.  
  113. Surely Apple should consider putting a real mechanism for inter-application
  114. communication into MultiFinder. I suggest that each application register
  115. it's own unique name under MultiFinder. Then another application could go
  116. try and start a "conversation" with "EXCEL" for example. (This sort of idea
  117. is similar to DDE under Microsoft Windows.)
  118.  
  119. I could see MultiFinder inter-process communication, one day, working
  120. something like this:
  121.  
  122.        MFRegisterName ("SQLSERVER");
  123.  
  124.        for (;;)
  125.        {
  126.        /* this routine yields control until we get a request */
  127.  
  128.        client = MFWaitForRequest (¶mblock);
  129.        .
  130.        .
  131.        .
  132.        Process request
  133.        .
  134.        .
  135.        .
  136.        MFSendReply (&paramblock, client);
  137.        }
  138.  
  139.  
  140. Thoughts, anyone??
  141.  
  142.  
  143. Regards,
  144. Dave Jewell
  145. -----------
  146.  
  147.  
  148.  
  149.